Scenario #9039: A Deactivated Subject Is Reactivated by the Next Synchronization with the Same Uuid

When a subject reappears in Keycloak, e.g. because the external sync presumed it was deleted because of some sort of system failure or because it was simply disabled in Keycloak and got enabled again, the sync program simply synchronizes it again. And because the earlier removal was just a deactivation, the UUID-keyed PUT reactivates the retained subject: it keeps its UUID, becomes visible again, and the response reports an update (200 OK), not a creation.

This is necessary so that explicit RBAC-grant’s don’t get lost too soon.

Properties

Required

• SubjectSync: sync-alice - deactivated from 9035: A Global Admin Can Deactivate a Removed Subject

Given

name	value
subjectUuid	238a0001-0000-0000-0000-000000000001
subjectName	sync-alice
subjectType	USER

Synchronize the subject via HTTP PUT

HTTP PUT "/api/rbac/subjects/238a0001-0000-0000-0000-000000000001" // SubjectSync: sync-alice \
  -H "Authorization: Bearer $HSADMINNG_JWT_BEARER" \
  `# {` \
  `#   "sub" : "uuid<hsh-alex_superuser>"` \
  `# }` \
  <<EOF
{
  "name" : "sync-alice",
  "type" : "USER"
}
EOF
=> status: 200 OK 

The stored subject carries the expected organization

HTTP GET "/api/rbac/subjects/238a0001-0000-0000-0000-000000000001" // SubjectSync: sync-alice \
  -H "Authorization: Bearer $HSADMINNG_JWT_BEARER" \
  `# {` \
  `#   "sub" : "uuid<hsh-alex_superuser>"` \
  `# }`
=> status: 200 OK 
{
  "uuid" : "238a0001-0000-0000-0000-000000000001", // SubjectSync: sync-alice
  "name" : "sync-alice",
  "organization" : "sync",
  "type" : "USER"
}

---

generated on 2026-08-10 04:42:42 for branch HEAD